Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for adaptive application of authentication policies.
Description of Related Art
FIG. 1 illustrates an exemplary client 120 with a biometric device 100. When operated normally, a biometric sensor 102 reads raw biometric data from the user (e.g., capture the user's fingerprint, record the user's voice, snap a photo of the user, etc) and a feature extraction module 103 extracts specified characteristics of the raw biometric data (e.g., focusing on certain regions of the fingerprint, certain facial features, etc). A matcher module 104 compares the extracted features 133 with biometric reference data 110 stored in a secure storage on the client 120 and generates a score based on the similarity between the extracted features and the biometric reference data 110. The biometric reference data 110 is typically the result of an enrollment process in which the user enrolls a fingerprint, voice sample, image or other biometric data with the device 100. An application 105 may then use the score to determine whether the authentication was successful (e.g., if the score is above a certain specified threshold).
Systems have been designed for providing secure user authentication over a network using biometric sensors. In such systems, the score generated by the application, and/or other authentication data, may be sent over a network to authenticate the user with a remote server. For example, Patent Application No. 2011/0082801 (“'801 application”) describes a framework for user registration and authentication on a network which provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “malware in the browser” and “man in the middle” attacks for transactions), and enrollment/management of client authentication tokens (e.g., fingerprint readers, facial recognition devices, smartcards, trusted platform modules, etc).
The assignee of the present application has developed a variety of improvements to the authentication framework described in the '801 application. Some of these improvements are described in the following set of U.S. Patent Applications (“Co-pending Applications”), all filed Dec. 29, 1012, which are assigned to the present assignee and incorporated herein by reference: Ser. No. 13/730,761, Query System and Method to Determine Authentication Capabilities; Ser. No. 13/730,776, System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices; Ser. No. 13/730,780, System and Method for Processing Random Challenges Within an Authentication Framework; Ser. No. 13/730,791, System and Method for Implementing Privacy Classes Within an Authentication Framework; Ser. No. 13/730,795, System and Method for Implementing Transaction Signaling Within an Authentication Framework.
Briefly, the Co-Pending applications describe authentication techniques in which a user enrolls with biometric devices of a client to generate biometric template data (e.g., by swiping a finger, snapping a picture, recording a voice, etc); registers the biometric devices with one or more servers over a network (e.g., Websites or other relying parties equipped with secure transaction services as described in the Co-Pending applications); and subsequently authenticates with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices). Once authenticated, the user is permitted to perform one or more online transactions with a Website or other relying party. In the framework described in the Co-Pending applications, sensitive information such as fingerprint data and other data which can be used to uniquely identify the user, may be retained locally on the user's client device (e.g., smartphone, notebook computer, etc) to protect a user's privacy.
For certain classes of transactions, the riskiness associated with the transaction may be inextricably tied to the location where the transaction is being performed. For example, it may be inadvisable to allow a transaction that appears to originate in a restricted country, such as those listed on the US Office of Foreign Asset Control List (e.g., Cuba, Libya, North Korea, etc). In other cases, it may only be desirable to allow a transaction to proceed if a stronger authentication mechanism is used; for example, a transaction undertaken from within the corporation's physical premises may require less authentication than one conducted from a Starbucks located in a remote location where the company does not have operations.
However, reliable location data may not be readily available for a variety of reasons. For example, the end user's device may not have GPS capabilities; the user may be in a location where Wifi triangulation data is unavailable or unreliable; the network provider may not support provide cell tower triangulation capabilities to augment GPS, or Wifi triangulation capabilities. Other approaches to divine the device's location may not have a sufficient level of assurance to meet the organization's needs; for example, reverse IP lookups to determine a geographic location may be insufficiently granular, or may be masked by proxies designed to mask the true network origin of the user's device.
In these cases, an organization seeking to evaluate the riskiness of a transaction may require additional data to provide them with additional assurance that an individual is located in a specific geographic area to drive authentication decisions.
Another challenge for organizations deploying authentication is to match the “strength” of the authentication mechanism to the inherent risks presented by a particular user's environment (location, device, software, operating system), the request being made by the user or device (a request for access to restricted information, or to undertake a particular operation), and the governance policies of the organization.
To date, organizations have had to rely on a fairly static response to the authentication needs of its users: the organization evaluates the risks a user will face during operations they normally perform and the requirements of any applicable regulatory mandate, and then deploys an authentication solution to defend against that risk and achieve compliance. This usually requires the organization to deploy multiple authentication solutions to address the multitude and variety of risks that their different users may face, which can be especially costly and cumbersome to manage.
The techniques described in the Co-pending applications provide an abstraction that allows the organization to identify existing capabilities on the user's device that can be used for authentication. This abstraction shields an organization from the need to deploy a variety of different authentication solutions. However, the organization still needs a way to invoke the “correct” authentication mechanism when necessary. Existing implementations provide no capabilities for the organization to describe what authentication mechanism is appropriate under which circumstances. As a result, an organization would likely need to codify their authentication policy in code, making the solution brittle and necessitating code changes in the future to enable use of new authentication devices/tokens.